【レポート】どこから手を付ける？！ レガシーシステムだらけな 北の大地の生協がAWSにAll inしたら #CUS-10 #AWSSummit

こんにちは！コンサル部のinomaso(@inomasosan)です。

AWS Summit Online Japan 2021が、2021年5月11日(火)、12日(水)で開催中されております。

本記事は2021年5月12日(水)に行われた「どこから手を付ける？！ レガシーシステムだらけな 北の大地の生協がAWSにAll inしたら」のセッションレポートとなります。

セッション概要

"ゼロから始めるクラウドジャーニー。生協が歩み出したレガシーからAWS All inへの第一歩とは？旅に出るヒントを公開！" さて問題です。 あなたは長年の増改築と多岐にわたる事業故にレガシーで複雑化したシステムだらけな企業で、ゼロからAWSを使うことになったらどこから何を始めますか？ コープさっぽろは昨年から全てのシステムをAWSへ移行する方針を掲げ、多数のエンジニアを採用しました。 そんなコープさっぽろでゼロからAWS設計をした、リアーキテクティングをしたストーリーを同じ悩みを抱えるあなたに贈ります。

登壇者

生活協同組合コープさっぽろ デジタル推進本部システム部 インフラチームリーダー 若松 剛志 氏 生活協同組合コープさっぽろ デジタル推進本部システム部 エンジニア 山﨑 奈緒美 氏

セッションレポート①(AWS移行)

1. アジェンダ

ゼロからAWSにAll in

• どうやって持っていくか
• どのように計画を立てたか

2. コープさっぽろシステムの現状

レガシーなシステムで、OSもかなり古くネットワークも複雑かつ、基板ごとに担当者がいる。
その数は190システム、650サーバもある。

3. アカウント設計

・アカウント管理

最初から複数アカウントを運用する前提で全体をAWS Organizationsで設計。
実は既存で数アカウントあって苦労しているので最初が肝心。

・ログイン

他社SaaSを中心にID管理をしていたので、IAM+IDプロバイダ+他社シングルサインオンで、AWSマネージメントコンソールにログインできるよう設計。

・ポリシーに違反しているリソース検出

ポリシーに違反しているリソース検出はAWS Security Hub & AWS Configで設計。
AWSで事前に定義されたルールを適用し、作り込みは一旦しないことにした。

・ネットワーク

AWSアカウント間はAWS Transit Gatewayで、AWSとオンプレ間はAWS Direct Connectで接続。

4. オンプレからの移行

・移行方式

まずはAWSにLift(V2V/P2V)するところから始めた。
クラウドネイティヴな構成へのShiftは、Liftが完了してから考える。

・システム/サーバのリスト化

OS/MWをコピーする条件を確認。
かなり古いOSなのでツールインストール不可や、データベースだとライセンス問題に絡んでくる。
また、ハードウェアやアプリケーションの保守期限を確認し、移行の優先順位漬けに利用した。

・移行ツール

以下のような利用からCloudEndure Migrationを選定。

• ダウンタイムが少ない
• AWS Direct Connect経由の移行が可能
• 帯域制限が可能
• 直接VPCにコピー可能

AWS Server Migration ServiceはS3を経由する必要があるのも、CloudEndureを選んだ理由の一つ。

AWS Application Discovery Serviceを導入し、AWSに通信状況をキャプチャすることで、AWSへ移行後のセキュリティグループに何が通信許可が必要なのか把握した。

・Active Directoryの移行

ActiveDirectoryはサーバでしか利用していなかったので、クライアントPCの考慮が不要だった。 移行先マネージドサービスのAWS Directory Service for Microsoft Active Directoryにした。

5. これからのシステム構成

何故かネットワークの中心がコープさっぽろ本部であり、データセンターも3つと冗長なため、データセンター中心のネットワークを目指す。
ゆくゆくは、インターネット中心のネットワークとし、構成をシンプルにし障害点を減らし運用を楽にしたい。

セッションレポート②(宅配サイト インフラリニューアルの裏側)

1. アジェンダ

全体設計前に孫座していたアカウントのインフラ構成をリファクタリング。

2. サイト・アプリのリニュアル

2009年からあるサイトのUIが古かったり、スマホで使いにくかった。
既存開発ベンダーと、内製開発エンジニアリングチームで４ヶ月でサイトリニューアルした。

アプリもログインをID/パスワード方式ではなく、Auth0を使った認証コードによる方式に変更したり、SNSログインも追加した。

3. インフラ構成の課題

リニュアル後のインフラ構成で、環境が全て同じによるオペミスが発生したり、組織単位のリソース共有がきかなかったり、踏み台サーバの取り合い等の、数多くの課題が発生した。

4. インフラ構成のリファクタリング

• アカウントの分離
• インフラアーキテクチャの改善
• Observability(可観測性)のために、NewRelicによるインフラリソース、アプリの監視を実施

5. ロードマップ実現時の課題

想定される課題としてAPIリクエスト数増や、スパイクアクセス時のDB負荷増等が挙げられる。 こういった課題に対し、スケールアウトに着目し検討する順番を決めた。

• コンピュート
  • AWS Lambda
  • コンテナ
  • EC2
• データベース
  • Amazon DynamoDB
  • RDS or Aurora
  • EC2

6. 事業会社にこそAWSスペシャリストを

クラウドの利用により情シス主体でコントロールでき、システム開発の面白いところをベンダーに任せなくて済む。 そのためには魅力的なキーマンの存在が重要になる。

今こそ情シス部長の熱い気持ちや夢を求人の候補者にぶつけて、野望の実現に乗っかってみたい人材獲得を！！

まとめ

レガシー環境をAWSに移行する際のポイントが、簡潔にまとめられているセッションでした。
LiftとShiftを一緒に実施するのは、ハードルが高いのでまずはLiftから始めるのが成功の鍵の一つだと思います。

セッション概要にあるクラウドジャーニーという言葉の通り、クラウドは継続的なシステム改善が必要です。 そのために、ユーザ企業はAWSスペシャリストを確保するのが今後重要になるのではないでしょうか。

この記事が、どなたかのお役に立てば幸いです。それでは！